Embodiments of the present invention generally relate to telecommunications and more specifically to techniques for providing an interface to allow a network application to offload stateful operations to a user plane function.
When an entity moves from a legacy system to an internet protocol (IP) system, certain decisions have to be made on how to architect the IP system. Legacy systems provide reliability and if this reliability is to be preserved, the entities may use a big iron approach to the IP service deployment. The big iron approach uses fault-tolerant hardware and stateful inspection. This approach, however, ignores the load balancing and system-wide resilience capabilities that are provided by an IP system. Further, fault-tolerant big iron systems are often costly to deploy. This minimizes the advantages for switching to an IP system.
Applications in IP systems also require that functionality be stateful to meet the business requirements of the service providers. For example, in a wireless domain, users may commence an IP session while in radio coverage. However, due to changing conditions, such as user movement, degraded radio coverage, or loss of connectivity, the user may lose connectivity. Without maintaining state for the user, the session may hang because a system needs to associate the IP session with the user who has lost coverage. Accordingly, service providers need to define functionality that uses state to clear up the sessions on behalf of the user who has lost radio coverage.
In other examples, functionality also requires stateful operation when policing session initiation protocol (SIP) messages. Service providers may require that SIP messages from a user pass through a specific service provider element (such as a SIP proxy) that is used to generate billing information or used to include subscriber policy information as to how to route the particular SIP message. Functionality is defined to provide a stateful solution for the SIP proxy. For example, upon registration, the SIP proxy may receive a SIP service-route header that is used to make sure messages are routed through the SIP proxy. However, some users may try to circumvent the service provider charging and policy control by including information in the IP message that causes the SIP message not to be routed through the SIP proxy. For example, a user may ignore the service-route header and insert another set of routes in the route header to cause the SIP message to avoid passing through the SIP proxy. To combat this scenario, the edge proxy may be used to police the SIP messages to ensure that they are routed through the desired element. For example, an edge proxy may maintain the state information by caching the service route header. The edge proxy then polices any SIP messages received from the user and can make sure the correct service route header is included in the SIP messages. This, however, requires that the edge-proxy be stateful.